"Workflow management software" has gained acceptance in the past few years as a medium for automating traditional office processes, such as, for example, processing of insurance claims. Briefly, the function of workflow management software is to provide specific sets of information, such as individual documents, to a series of persons, or other entities such as computers, in a given sequence so that the various persons or other entities can, for instance, approve, modify, or otherwise process the information according to a pre-designed total work process.
In a common commercial version of workflow software, such as that sold under the trade name "InConcert.TM.," a collaborative process is defined as a sequence of "tasks." A "task" can be generally defined as an instance in which what is called an entity (such as a person, one of a predefined group of persons, or a computer or printer) is assigned a "role" having a specifically-defined interaction with a set of information, through what is called a "binder." A binder, for present purposes, is a reference to some quantity of data, such as a document or a quantity of code, such as would be derived from, for example, a form filled out by a customer. A plurality of tasks are assigned interrelations, such as a sequence, which may have finish-start (FS), parallel, alternative, or if-then paths, to form the entire process. (Formal definitions of these terms, as they relate to the present invention, will be given below.) In the specific case of InConcert.TM. software, these individual tasks are each assigned an icon by type (such as "approve," "fill out form," "send to manager," etc.) with these icons being arranged by the designer of the process on a graphical user interface.
In the traditional model of applying workflow management software to a real-world process, such as processing an insurance claim, the basic process, meaning the arrangement of tasks forming the process, is established a priori by a process designer, who in effect imposes the process design on the persons and systems who will carry out the process. The burden falls on the process designer to do the initial "research" into the objectives and requirements of the entire process, and the people who collaborate on the workflow must conform to it. It has been found, however, that in practical applications of workflow management software, a process designer often does not have enough information or practical insights to successfully design the workflow of the process ahead of time. It is more likely that persons who have traditionally carried out the process will have greater knowledge of certain nuances of the process that would not be apparent to a process designer. In some cases the persons who are to carry out the process can assist the process designer in developing the process definition, but this still incurs the effort and overhead of a priori analysis and cannot anticipate the variety of actual process executions that may occur when the participants actually carry out their work. The present invention is thus directed to enabling a system where an initial basic business process can be amended, and therefore caused to evolve as a result of ad-hoc inputs from various persons involved in the process while the process is running.